Modern networks provide great advantages by allowing computers and other communicating entities to exchange information. Networks can comprise a number of component devices. Such network devices can include routers, switches, and other components. Such devices are typically programmable for setting their operating characteristics and controllable for changing these characteristics as well as for eliciting certain operations or functions.
Conventionally, device configuration is performed using command line interface (CLI), a graphical user interface (GUI), or by directly copying a configuration file to a device. For instance, to configure a router, a configuring entity can enter CLI, line by line, to the router. Using a GUI, the configuring entity can enter the commands for configuring the router by inputting entries graphically.
Such graphical inputs can include entry of text into graphical component fields, and/or using other graphically displayed computer based mechanisms. Conventional text editors, in contrast, copy a configuration file off the network device, allow the user to edit it, and then allow the edited file to be copied back to the device. The configuration file is typically copied in its entirety. Similarly, upon editing, the edited file is sent back to the network device in its entirety.
Using CLI to configure devices offers a number of convenient features, such as automatic command identifier completion and automatic display of available commands. For instance, using a keyboard to enter CLI information, after initially typing the first few letters of a command name or other identifier, a configuring entity user can simply depress the ‘tab’ key, and the CLI will automatically complete the display and entry of a corresponding command.
Another example of a convenience accorded to an entity using CLI to configure a device is the automatic display of commands. For instance, to display a list of all available and/or allowable commands at any given point in a configuration activity, a user can simply simultaneously depress the ‘shift’ and question mark/forward slash (‘?’ and ‘/’) key. Such conveniences are available to configuring entities, such as network engineers and administrators.
However, configuring devices using CLI is typically a process involving multiple steps. Also, changing the configuration of a device using CLI is performed, for example, by a manual keyboard, by which commands are entered on a line by line basis. Where the configuration being changed is large and/or complex, line by line changes can be tedious, time consuming, and/or possibly error-prone. There is also no easy way to see what configuration has been changed in an editing session.
Further, the alternative of copying an entire configuration to the network device to change a device configuration can be time consuming and error-prone as well as consuming computing (e.g., processing) and networking resources and rendering the device unavailable during the configuration change. For instance, consider a typical router configuration comprising several hundred thousand separate data objects wherein to effectively change the configuration as needed a single object is to be changed.
In this instance, the configuring entity establishes contact with the router via Telnet and logs on thereto. The configuration is then copied off the network device and modified. Upon completing the input for the configuration change, the old configuration is deleted, in its entirety, and the new configuration loaded. To load the new configuration, the router must be restarted, after a shutdown. The new configuration is loaded during the boot up of the router.
Besides the time and tedium that can characterize this approach, as well as the possibility of inadvertently inputting an error while completing the changes, this method takes the device off line, rendering it unavailable for use. Also, network resources are consumed by retrieving the entire existing configuration from the router and sending the newly changed configuration back to it. However, where only a single object is to change, this consumption can be somewhat inefficient.
During rebooting the router and loading the new configuration, more time and resources are consumed, and another opportunity for errors arises. Rebooting takes time, as does loading and parsing the entire corpus of the new configuration (not just the changed object). During this time, the router remains unavailable. The loading and parsing of the new configuration can consume significant computing (e.g., processing and memory) resources while they transpire.
Further, whenever a configuration is changed, especially when, such as in the instant example, it is changed in its entirety, some probability exists that errors, such as transcription errors, exceptions, and the like, can occur. Such errors can further disrupt operation of the device and consume even more time and resources to debug and correct. For instance, the boot process can fail, the configuration can fail to load, or if loaded, can cause the device to operate improperly, etc.
Where a GUI is used for configuring a network device in lieu of configuring using CLI, some of the issues discussed above affecting CLI configuring can be ameliorated to some extent. However, in using a conventional GUI in lieu of CLI to configure a device, helpful and desirable features of the CLI configuration technique may not be available. For instance, a conventional GUI does not make the automatic command completion, help, and syntax check features available. In addition, a GUI does not offer the user individual command flexibility or a single view of all configuration and associated hierarchy.
Conventional text editors used for configuring a device in lieu of configuring using CLI either do not support parser based features or require the CLI language of the network operating system (OS) be imported into the tool to provide such parsing features. Lacking parsing features can add tedium, difficulty, and/or increase the probability for error. Also, the application must be maintained to remain current with the version of the OS running on the device. These issues can also apply to GUIs.
Requiring import of the device CLI language and/or maintaining currency with the device's OS version add complexity to the tool and demand additional resources. Further, conventional text editors operate to configure devices by overwriting entire configurations or configlets. For instance, conventional text editors copy configuration files off the device and copy edited files back to the device, both in their entirety.
Further, conventional device-resident text editors that are used for such applications operate under constraints of memory, processing characteristics and OS of the device. Also, conventional device-resident text editors cannot easily be extended (e.g., as they are part of the OS). Further, conventional device-resident text editors can be hindered in interacting with other off-device software and/or in operating with other devices.